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INTELLIGENT HELP SYSTEM 

COPYRIGHT NOTICE 
A portion of the disclosure of this patent document 5 
contains material which is subject to copyright protec- 
tion. The copyright owner has no objection to the fac- 
simile reproduction by anyone of the patent document 
or the patent disclosure as u appears in the Patent and 
Trademanc Office patent file or recoros. but otherwise J0 
reserves ail copyright rights whatsoever. 

FIELD OF THE INVENTION 
This invention relates to help systems for computers- 
more specifically, it relates to help systems that aid a 13 
user of a computer by providing context sensitive help. 

BACKGROUND OF THE INVENTION 
In order to operate a computer effectively, a user 
must nmier a number of commands and data formats- *° 
> =1 ° ne accomplishes this by spending hours read- 

rj mg pnmed user documentation and/or by using tnai 

* nd crror techniques. 

01 Computer-aided help system have been developed to 

^1 providc on-line assistance to computer users. In re- 2* 

y - fponse to a request by a user, those systems display help 

b information on the display screen of the computer. Sim- 

plcheip systems always start with the same display, 
regardless of the circumstances, and the user must enter 
specific information to find help for his or her particular 30 
Wttfctton. More advanced help systems display context, 
•emiuve help. Context-sensitive help systems determine 
wr« particular P*" o{ application p r o gram the user 
ts m. Then help information is displayed that is relevant 
to this user location. 35 

While such context-sensitive help systems represent 
•advancement over simple help systems, they have 
numerous l imitation s. Such systems are usually tightly 
coupled to an application program; they must rely on 
™ application program to keep track of and store the 40 
r onfCTi . Further, since these systems are limited to 
displaying help infonnatum based upon p r n fl ! *m joca. 
□on. they will always return the same help information 
for a given location regardless of how the user got 
there. While such systems provide the convenience of 45 
on-l ine he lp, the help information they provide is noth* 
tog mo re than a user's manual correlated with a given 
program screen or function. As a result, fhyw? help 
«Y«*ms tend to be of limited utility to the user who 
cannot specifically identify the problem or who has 30 
Tost his way." 

SUMMARY OF THE INVENTION 
The invention recognizes a need for an intelligent 
help system which processes information specific to the 53 
user's history, such as tasks he or she has successfully 
executed (and how many times) or has had previous 
hop with, and information which defines a state of a 
niachine and a state of a programmed application. 

According to the invention, an intelligent help system 60 
for aiding the user of a computer program is provided 
by maintaining an historic queue and using artificial 
uiteiiigcnce techniques to select help information based 
on user-directed events and the current state of the 
system. In particular, user-directed activities are moni- 65 
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tored and stored in the historical queue inside a know!* 
edge base. System states are also monitored and stored. 
TTie knowledge base is then used by an inference engine 



5 



10 



to isoiate the soecitic iuna of heio that a user news, 
inus. the user 1s glVe n assistance UD on reauest wnich is 
appropriate to that users ievei of unaersianaine or 
experience zma the current activities tnat ne or sne has 
executea. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is a block diagram of a comouter svstem in 
wnich the invention mav t>e emoodicd. 

FIG. 2 is a block diagram of a comouter software 
system usea in the preferrea emoooiment. 

3A ^ urates the processme of user-directed 
events arid system states into heio in formation. 

15 u , U a flow cfaart ol " lhc generai methods of the 

heip system. 

dev?ci' 4 ^ * fl ° W Chin °' * qUCrV by ,he mon »°nng 

FIGS. 5A-8 are a flow chart of the methods of the 
20 cveni interpreters. 

y FIG. 6 is a flow chart of the methods for processme 

ijvr. events. ~ 

W a ™- 7 is a ,low c "an of the method* for identifying 

ij - 3 2S" ! i, ' UIIrit « «»« ™ie taxonomv o. the invention. 

| knowtea' e ! lH ~' ' rima — —f ™ 

tfl " GS " I0A ~ 3 " e a n ° w of the methods for 

proving rules. 

_ JO FlG - illustrates the operation of the display engine. 
G1 DET AILED DESCRIPTION OF THE 

2| PREFERRED EMBODIMENT 

S iJ^SZT* W ^ L ^ embodiment of the 

\* U " '« P*ente«e d on a computer system 100 

]| Javmg > centr^ proc==or 10i a system memory 103. a 

devtee * keyboard 106. a moos. ,07. a disk 
tf5 fal""''!' 1/0 owwiler 101. and interconnect- 

ujg mem no. such ax a system bus. In the preferred 
40 obodunent. a Tandy 1000 series COTpwer^andv 
Corpora of Ft. Wordu Tea.) i. ^e^ ^^ 

« <°r p r og r ammin g the computer system of FTC 

Tnf^ Sv «« «0 pro^asi the 



««™ processor 102 to dupiay a graphic user mterface 
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. - 1 -203 which provides a software 

b «^«-««- 204. a^apsoer^p^! 
*■ 002. aad an operating system 201. It will be ippT. 
«^ho««ver that one of ordinary skill in the arTm- 

M Sot ? ,£* TOllaaan - implement the in. 

53 venoon in other operating environments. 

fAn „JLT fCTTetJ enstxx± " ncnt - » aroficiai intelligence 
(AO paradigm » used to deal wi,„ knowledge which 
may be vast and uncertain, lading to multiple solutSns 

«0 lear^ TrZ^"^^ M m0del h » > bi ««V " 
bi n , 00re »«owledge from what it already 
know*. Thus, if a user requem help and the help system 
cannot reach a solution, the system can get ferme? 

«Tot?„" ( ! ,0n fr0rn * he ^ ^ ,h « 'emembe g r hlTtua! 
65 IThl ,,n,C th " , ,h " «"«•">» occurs a solut^n 

^^JT" W, ^° U ' " uervm 5 again. 

foT^H COmDTOa « -"oniionng device J20 
for collecting data generated - 



in response to user- 
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£d£ M eVem$ a " d SVS ' em S,ares a knowledee base 
datable 335 usca to octcrm.ne .he best heio to g,ve. an 
Terence enpne 340 for .n.erpret.ng data 331 and heto 
u»orma„on aatabase 335 in knowledge base 330 and , 5 

format.on 360 on a.spiay dev.ee 105. Data 331 com- 
pnses an n.stoncai Queue 332 and a state data 333. while 

J£ srsss? ~ 335 compn ~ a ^"<* * 

cJUSi 3 ? '* 3 n ° W Chan ,,lu "«ung the general meth- '° 
ods of help system 300. In step 351. user^.recteTevena 

^oncciea in step 351 is stored as facts or data 331 rt f 
directed events are stored in historical queue 332 anri 
in step 353 .fa user requests heio (e.g.. pressing Fl kevi 

3r.«2 , h i f ,nfcre,,Ce ^ ««^owi d7ta 

«I against help system rules 334. However if no h- n 

« requested .„ step 353. the routine loops backTo the * 
monitoring step 351. e 

^ZuZ^r 3 {° " 0r r heu ™'« « ««« form of 
mics. kujcs 334. such as those used tn «t~~ ace 

sdecting an output. For example, suppose a^isin a 
Text (word processing) iistboa and nofita L^L^ 
A ruie that wouid **rr fc thi, is: sheeted. 

35 

if 
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23™* u ,he kaow " data in knowledge 
rwa wiiii .his premise u tnar conclusion. Next, if in a* 

«boJmen, desenbed hereafter with rSSnce w so 

Monitoring device 320 and its functions will now be 
described tn dettiL While monnonng device^ r ?«c£ 
or monitors user input, it has processing canabUitiel n 

a sequence of one or more events or stales . mv y r . s 33 

.on«er 0 ,rue ,R,CI *"* ^ -<=«™ e no 
3'™ e - ' new value for old data. It 

ieXl v k ,hC "? mbCr of Iuna ™ *«ivi«y has suc- 
cessfully been completed by a user «n 

in ft!^r ,,0nnS dCV,CC 320 monitors different types of 
ST%££¥* m *f hi " e ««. application^.' 

of accessories mcludea pop-up calculator, calendar? or 
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alarm. A comoonem is a graphic ciemcni that a user 
interacts with to display and accept information irom a 
user. For examDie. the components in a diaioeue oox 
include radio buttons, push buttons, and edit fields. The 
5 menuoar is also a component. 

Monitoring device 320 also monitors appiication- 
specific states tappiication specifics), including informa- 
tion unique to an application, and component states, 
including information within the current machine state 
10 which is either application specific or general; since 
components such as radio buttons are generated in the 
same way. regardless of whether the component is used 
at the application level or generai level, information 
i about component states is also generated in a uniform 
manner. For example in ail applications which have a 
menubar. choices are obtained by selecting an item oiT 
the menu. 

Monitoring device 320 also tracks historical informa- 
2Q tion which indicates the completion of a task for which 
help has been defined. This data is stored in historical 
queue 332. A successful completion indicates that the 
user no longer neeas heio in performing that task. More 
specific help information, rather than generai informa- 
23 tion. can be given as the user gams more experience 
with a program. 

The structure of historical queue 332 will now be 
described in detail. For each entry, an entry type is 
stored. For example, when a user runs a dialogue box. 
J0 monitoring device 320 adds a dialogue box entry 
( CMP — DLG-BOX) into historical queue 332 and then 
stores corresponding editfield. Iistbox. radiobutton. 
tconbutton and checkbox information. Pi rn entry into 
historical queue 332 can be of variable length, depend- 
33 iag on the type of entry made. A unique "return code" 
*** | S ne d to each component, thus facilitating the 
distinction between compon ents. A far pointer to an 
entry's structure <e.g^ dialogue box, component, and/or 
menubar structures) is stored to allow direct a ^rii to 
40 that structure. Following this, dialogue and component 
information is copied. The format used can be of vari- 
able length. A subemry flag is defined to indicate when 
there is a subemry. For example, a c omp onen t may still 
be running while the menubar is processed, therefore. 
45 the menubar is pan of a single entry. If the flag is set to 
a value of true, then any subemry data is stored. An- 
other flag is defined to indicate the user keystrokes that 
ocearred during the entry. This enables the system to 
determine, for example, whether the user has begun 
50 entering data into a dialogue box. or if he chose help 
immediately. The name of the box and menu entries, 
such as DLGBOX. MSGBOX. LISTBOX. or MENU, 
is stored to distinguish one box from another. A third 
N " defined to indicate the user keystrokes that oc- 
55 curred before invoking help. This enables the system to 
determine what the user was doing in the application. 

Variables which manipulate historical queue 332 are 
defined as follows: 

ihm H eJpQ: the 500 byte queue, there is one in each 
60 task data area of the Core Service Routine (CSR). 
ihnwTOP: the physical start of the HeipQ butter, 
i hm FN DQ: the physical end of the HeipQ buffer, 
ihm— stan_ptr: pointer to the first entry in the queue. ( 
which is last historically). 
65 ihm_cur_ ptr: pointer to the first byte of the last entry 
in the HeipQ. 

ihm_cnd ptr: pointer to the last byte of data entered 
into the HeipQ. 
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ihm_save_ otr: the ptr vaiue of the last entry made, 
saved because an mvaiid pir is emereo into the HeioO 
as a NULL. 

ihm_menu_otri: double wora pointer to the current 
rnenubar. Updated each time mb draw is cailed. 
The data structure 01 the aueue raav be summarized 

as follows: 

dw — offset of previous entry 
dw — iype 
dw — return code 
dw — struct ptr — offset 
dw— struct ptr— segment 
do — # subemncs 
db — length of name 

^ (? nam e of dJg box. msg box. menu. Jistbox 
db key flag— any mouse or key events before entry? 
db(? >— «u ben try data 

db— kcyflag — uiy mouse or key events during entry? 

dw — length of information copied or 0 20 

In the preferred embodiment, the monitoring of infor- 
mation occurs at different places in software system 
200. All state changes that result in the execution of 
dialogue ano message boxes are monuorea. In Desk- 
Mate environment 203. commands are entered by the 25 
user through a rnenubar and are processed by event 
interpreters, which check for rnenubar changes. In addi- 
tion, the application programs themselves may indicate 
state changes in their respective working areas. 

DeskMate environment 203 is divided into the fol- 30 
jownig hierarchy of level changes, thus simplifying the 
monitor s task of updating information: 

L T op Level to appiicaxion/accessory or menubar/- 
component: 

2. App lication to accessory or menobar/component 35 
or return to top level; 

3* Accessory to memxbar/component or return to 
application or top level. 

Specific information is r equired as to the following 
states: application is running or has quit; which appiica* 40 
l^. " rUimil>g; zcceaary «■ naming or has quit; which 
*™. rii wy * * rttnmng; dialogue boa is running or has 
quit; message boa is i mining or has qmc component is 
nammg or has quit; memibar menu has been pulled 
down or has returned; user at desk top; if user not at top 45 
level, the level attained prior to the current one. The 
variable "level" takes the value of DeskTop, Memibar. 
S g "j >OX ' M fW a y - PO *. lofo-Jboa. or Component. 
The monitoring can obtain the state changes by getting 
the address calls from DeskMate environment 203 50 
which indicate a f unctio n call to an application pro scram 
or resource. 

FIG - * illustrates how monitoring device 320 queries 
tfac >ddfqa of calls it is interested in. In DeskMate 
environment 203. applications call core service routines 55 
(CSR) to run components and dialogue, information. 
and me ssage boxes. A rnenubar interpreter handles the 
Processing of the rnenubar. Therefore, independently of 
in application, the calls which change the structures 
that the application is using can be monitored to keep oo 
'rack of information changes. 

Thus, the steps are as follows. In step 401. an entry 
call is m ade to a core service routine, in step 402. the 
component type is identified and then compared with a 
list of components that monitoring device 320 is inter- 65 
ested in. In step 403. if the component is listed in the 
isble. then tn step 404. monitoring device 320 lakes the 
application s parameters and its structure pointer to 
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copy data from wichin the application s structures The 
structures are not modified. Upon exit of the service and 
before controi is returned to the application, at step 405 
monitoring device 320 again accesses data in the stoic- 
5 tures. tms time for the purpose of histoncai information 
updates. 

Since a distinction may be made between aopiications 
and accessories, a variable '-program" is defined to 
inaicate wnich panicuiar program is running Program 
10 takes the vaiue of the program name, which is the same 
identiiier for help information database 335 associated 
with the application or accessory. 

Two event interpreters pick up raenubar chances 
The menu selected is important for the state, while "the 
15 item returned is important for the history, a high-pn- 
onty event interpreter picks up the menubar changes 
when help is requested, and a iow priority event inter- 
preter will make all changes from the menuoar's return 
m , n J?**' The h 'gh-pnoruy tnterpreter examines events 

W 20 first before any further processing by the DeskMate 

H£1 system. On the other hand, the low-pnontv internreter 

LiJ examines events alter they are processed bv the Desk- 

y Mate svstem. 

i i , c FIGS - 5A " B illustrate the method of the events inter- 

preters. in step 501. the application registers trie menu- 
M3 ° ar Wlf n monitoring device 320. At step 502. if the user 

ffi ** icctc * tne Fl f h dp) key. then at step 503 the state 

M information is updated according to what level the 

* system is operating at (indicated by the variable 

L 30 " Ievci ">- ""level equals zero tn step 504, then the menu- 

0 *** u lhe Jast tnin S changed, therefore a menubar up- 
Sj ' ™? 11 nceded * Al "*P MS- the menubar interpreter 
y, Bul if "level" is not zero, then step 505 

1 ] „ !l** PP ! d - At "*P ^e low priority interpreter 
V 33 checks the event type If, at step 507. it is menubar (level 

© - me nubar). then in step 508 the iow priority inter- 

d!J doca * history update, per f o r med by taking the 

renini code «nd comparing its value with the menubar 
menus. The string corresponding to the return code is 
40 the item of interest. At step 509, the routine loops back 
to step 501 to await another Fl keystroke. 

Tne r uies associated with the functions of the above 
components are written such thai if a component has a 
« "™* » uscd » identify its heip source. 

43 " a component does not have a title string, then the 
name of the component will be used as its identifier. 

Since a ll aopiications use the features of OeskMate 
emmonment 203. standard representation of data 331 
and rales 334 is possible. For example, the following 
50 variables can be used to indicate events and states: 
rami selected 
tnenuJtexn-seiected 
dJg.boxjiinning 
d]g.boz.focus 
25 msg. box. running 
cmp. running 
lutbox.itenxseiected 
cneeJcbox.itcm.seiected 

Application-specific information is obtained by hav- 
60 ing the application assert data into the current state data 
333 in knowledge base 330. The application .ccom- 
plishes this by making a call to an "Assert" function 
with the parameters "variable" and 'value." which are 
pointers to strings. The variable should match a variable 
65 ui the rule premise. ,.e., the rule must be defined before- 
hand. An application should assert anv historical infor- 
mation related to its unique state configuration. AppJi- 
cation data are removed from the current state data 333 
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by the application once those data are no loneer true by 
caiimg a ■Retract" function. Although tne aopncations 
may directly assert data into knowledge oase 330. they 
do not determine what help to give. Insteaa. they sup- 
ply the inputs for this determination. 5 

Historical information is obtained by using a user's 
^D. to index the user s unique historical information. 
This historical information is updated at the end of a 
task completion. For example, when the user has suc- 
cessiuily executed a copying function, monitoring de- 10 
vice 320 recognizes this by checking that the user has 
selected "text" and then seiected "copy " from the file 
menu. Having determined that the user has mastered 
this task, monitoring device 320 updates the user's his- 
torical information. For historical information associ* 15 
ated with the application s specific data, the application 
updates the information itself by calling the function 
UpdateHistory with a parameter pointing to a string 
representing the activity just completed. 

FIG. 6 summarizes the method for processing the 20 
events from the event interpreters. At step oOI. events 
are processea by examining the mouse coordinates and 
event type ana value, in step 602. events are identified 
by trying to Tire" or trigger a ruie that would make a 
data assertion or retraction into knowledge base 330. 23 
These rules represent ail conditions that must be true for 
data to be asserted or retracted. If a rule fires in step 603, 
then the event is identified, step 604. If the rule does not 
fire, then the event is not identified, step 60S. 

FTG. 7 illustrates the approach used in step 602 ( FIG. JO 
6) to identify a task (sequence of events). In step 701. a 
key or mouse event is examined. In step 702. if the event 
does not match the first premise line in any rule associ. 
ated with the system level, then the event is discarded in 
step 704. Otherwise, in step 703, all rules that fire are 33 
pl *f ed ° n A 8end*» which represents the most likely 
task/s). At step 703. the rules are approved or disproved 
by examining the next key or mouse events that come 
tn. Ifall the rules in the Agenda fail at step 706, then the 
first key analyzed is discarded and the next key h used 40 
to search for new rules, step 708; otherwise in step 707, 
the Agenda is cleared and the procedure loops to step 
701 to examine the next key/mouse event. 

Since the information mosmored is dependent upon 
the machine state level, the data generated are divided 45 
* cco " nn g tnc« levels. Monitoring device 320 attempts 
to assert data which apply to a given level. Each appii- 
cation or accessory can be consider ed as a distinct ob- 
ject (as a level) which peifuims certain activities; ^rrmr 
of which are common to other objects. Therefore, it is 50 
convenient to divide the monitor's data structure into 
i rames. " A frame contains the activities that ~**h ap- 
plication is capable of. with current values and histori- 
cal information- The frames have slots for storing the 
dau used by the rules or a pointer to another frame. 55 

In the preferred embodiment, user input and system 
state are analyzed by monitoring device 320 for passage 
a* dau to knowledge base 330 Tor storage. Commands 
are defined for controlling this flow of data to and from 
knowledge base 330. Data are stored in frames through 60 
the Assert command. Old information is deleted with 
the Retract command. A query is made to knowledge 
base 330 to attain information through a Query com- 
mand. Previous dau are asserted by a Reassert com- 
mand. 6J 

Knowledge base 330 comprises formal (traditional 
dau base information) and informai fheurisiic* knowl- 
edge which is ruie based. FIG. 8 demonstrates the ruie 



10 



8 

taxonomy. At the lower ievei of the ruie hierarchy 800 
is a single rule 804 defining a panem-to-action goal! The 
pattern is known as the left-hand side of a ruie. while the 
action ts the right-hand side. The mies use tne common 
logical ooerators AND. OR. and NOT. as weii as Bool- 
ean operators such as IF. THEN, and ELSE. In addi- 
tion^ the key word TEST indicates that a comparison 
needs to be maae. The right-hand side of a ruie can have 
an ELSE clause, an assertion, a retraction, another ruie 
or a procedure cail. For examoie. tn the ruie: 



IF a THEN b. ELSE c 

b could be an assertion which wouid add data b into 
15 data 331; multiple data assertions are possible A retrac- 
tion wouid delete dau b from data 331: 

IF i THEN CRHTRACT b) 



20 "Another rule" may be imbedded as follows: 
IF a then 6. IF (TEST bcii THEN d. 
An example of a procedure caii wouid be: 
23 IF a THEN (CALL HeJpTutonalUi). 

Linked Rules 803 are a linking between rules which 
share the same conclusion. This is a design impiemema- 
3Q tion intended to make the inference process easier by 
knowing alternative solution paths. Rule Groups 802 
group rules with a common purpose. For example, rules 
with a conclusion indicating what specific help to give 
w all rules determining the goal state, a group can 
33 , M <°P"onai) Priority identifier so the most impor- 
tant or most specific roles can be tried out first when 
«rcnmg Thu does not imply that a rule group will be 
lcft ^ of a sweh. Rules Classes 801 are a further 
coacem^uaiizarion of rules. They separate individual 
40 ^^^ge bases, each having a unique identifier by 
which it is distuguohed. This identifier can be used by 
a set of control rules which use the machine state infor- 
mation to indicate knowledge base 

mfl^.f?™*^ ^ contains formal or 

45 ulfo ™* i knowiedge. The informal knowledge becomes 
forxnal when a rule fires successfully. The formal 
to^dge is stored in and accessed from knowledge 
ba»330 ,„ frame structures. Frames can be made up of 
o tto f rames, which can also be shared. With this dau 
50 St f^ tm Z "» P°«We to access only the frame associ. 
ated t with the current state informauon when monitor- 
ing device 320 is updating the user's historical inform*- 
u J hc _ enmc * siou « like any linked iisL except 
they represent actions and attributes of an object or 
53 COnce f ta that frames represent. Since frames indi- 
cate the relationship between a user's activity and the 
associated heuristics used to interpret that activity, it is 
easy to access only relevant information. FIG. 9* illus- 
trates a frame 901 with its related slots 902. 
60 . . Ru,c ^ IaS f S a01 m made uo of Pointers to the van. 
2 0 ?*T f ~ m ^f™"- ™ c ^iots which contain 
another frame are really another group within a ruie 
class. In a frame- based reasoning system, one seiects the 
frame to prove by filling in siot values. The slots contain 
tne mies. The successful completion of a frame yieids a 
solution. 7 
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-continued 



<id> 

BEGIN. RULEG ROUP 

<id> 

IF 

( < variable > (S <v*j U e> * 
( <V«| UC > | 

f NOTf <vmaoie> IS < value > t) 
varuotc > £Q < 0 > » 

THEN 

( <vmJue> » 

END. RtTLEG ROUP 

END.RULECL^SS 
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By way of illustration and not limitation, the rules 
may be coded as data structures (illustrated in the C 15 
language): 



/* Prrmnc » * tcrociure canmamt ■ itneie puU m 
/• of a rule, it i t mmam uo ^ lh . nra , c |Uc|f (he (v 
/• of diu ti 11. tmt the poraote vaJue* it can Hold. 



uruct Premne 

( 

char *t>Vir 
char •pVaJtteSct: 
chax 'pVaJuc: 



/• Premise* n * uruciox* for mai—aimwa, • linked 
/* tin of ail ih« p r iuiu w mmgi) tn a unnic rule 






}; 



i RnkOroajp *pNe*t: 



/ Rules a • nnctmw nm i n aia a «ii the ruio «mh» 
/• a Rule Groa». racy cm bar uagaiav or — 
/* *nh on another. 



•/ 
*/ 
•/ 



V 
•/ 
V 
V 



Rules 



♦/ 
•/ 
V 
•/ 
•/ 



20 



Z5 



30 



33 



40 



45 



50 



55 



>; 



■tract I ioaadRuiea 'pLiaked Rules: 
char *pCoaciiflnaae 
Mm Rules -pNeit: 



/• UakcdRuio n a tcrucm for mamununv a linked 
/• tiat of roles which ail haw the un concstno*. a 
/• role a maoe up of p rmiiiu (ttracrarei • oonctttsmi 
/• (ttrmt) um a w«v luieacm lurtnil ciplantni 
/* why a rate » 



V 
V 
V 

•/ 

V 

V 
V 
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-continued 



struct LmkedKuiri 

{ 

^ Mruci Premtie* # DAIIPrenmev 

struct LintcoRulrt *pNe«i* 

J: 

*\ v 

/• Query c* a structure tor muntumns a linked list •/ 
/* of aJI the oucno tor iniormaiion utnngsj in the •/ 
/• tnowiedse ease , f 

10 /* . . / 



tiruet Query 

{ 

char *pF«ct; 
char •pAsk: 
chax *pSet: 
1 5 «"» Uuery -pNeic : 



The inputs to knowledge base 330 are the data coi- 
lected b monitoring device 320. The outputs of knowi. 
20 edge base 330 are aata 331 and rules 334 whjch infer- 
ence engine 340 seiects tor examination and help infor- 
mation text 336 which display engine 350 processes. 
Rules 334 are predefined by application deveiooer. The 
frames indicate the reiationshio between the user's ac- 
25 tivity and the associated heuristics used to interpret that 
activity, thus making it easier to access only the infor- 
mauon needed. The knowledge-based rules are struc- 
tured so that obvious associations between rules can be 
incorporated within knowledge base 330 simplifying 
30 Che design and the inferences from those rules. 

Inference engine 340 int er p r e t s data 33 1 and rules 334 
in knowledge base 330 to grve a help solution to the 
or « mtdiigeniiy asks for more information in 



order to obtain a solution. In the preferred embodiment. 
33 inference engme 340 operates using a backward-chain- 
mg method. This method starts with a goal state (a 
pmicuiar kind of help) and tries to prove it by reaching 
uxmai known data, 

Aa FIGS. I0A-B illustrate, the steps used by infer. 
Ullff en5 * n . e 340 are ** follows, in step 1001. knowledge 
*f Q ■* accessed according to the system state's 
lev * t In stc P *00i depending on the system state, a 
gnmp of rales (goal) is selected from knowledge base 
330 and used as an hypothesis. Next in step 1003 an 
43 attempt is made to prove each rule's conclusion by 
provtng its premise. i£ in step 1004. the premise exam, 
owd a the conclusion of another rule, it is pushed onto 
a stack (last-in first-out structure in system memory 103) 
and an anenrpt is made to prove the other rule's rjreimse 
l0 ° 5 ' 1x1 ,tCp A °°* tf * premise is proved, it is 
«rted into a working fact or data list at step 1007. 
Otherwise if the premise fails, a search is made in step 
1008 r or a roje ^ th the same conclusion, which infer- 



„ **** ^Pfe 340 will then try to prove. In step 1009. 
« when ail i the premises in the rule have been proved, the 
role has fired and the conclusion can be asserted at step 
1010. In step ion. this process is repeated until there 
are no more goal states to analyze or until no solution is 
round. In the latter case, knowledge base 330 is incom- 
es plete, therefore, inference engine 340 queries the user 
Tor more information or else explains to the user that no 
ne fP 15 defined for the particular scenario. 

The inputs to inference engine 340 are data 331 and 
rales 334 contained in knowledge base 330. Some of 
63 rules 334 control other knowledge bases which can be 
selected. Inference engine 340 first examines rules 334 
to select the proper rule class 801. Since the groups 802 
under the class 801 indicate if they are goal states, en- 
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gine 340 can aiso indicate which ruics wiii be usea as 
hypomeses. Hnai output from inference engine 340 is a 
heip "'Lag'* that indicates a pamcuiar heip solution, in 
addition, the engine creates a temporary output of data 
asserted whiie Droving the ruics. 5 

DispJay engine 350 is an interface between the output 
of inference engine 340 and heip text 336 giving the user 
easy access to the most useful heip topics. Display en- 
gine 350 proviaes general to in-depth heip to a user. It 
processes the inference engine's heip tag to provide 10 
Context-Sensitive heip. in addition, the heip information 
itself has tags which axe used by display engine 350 to 
locate further heip information. "This aJlows a user to 
select specific help from a subset of heip information. 

The heip information data structure used by display 15 
engine 350 is defined for each application/ accessory 
and system resource interfaces, Heip that is repeated 
across multiple applications is divided into groups. The 
heip information which is given is individualized for 
novice, intermediate, and advanced users. A display 20 
format is used which allows a user to select a single item 
of heip from a suggested list, allow the user to continue 
selecting help until he wants to qua. and allow the user 
to searcn througn the Help Topics for a particular 
topic. ^ 

The structure by which the help information is ac 
ceased and stored is classified according to appiication- 
/accessory or system component (requires specific 
name identification, not type), experience level of user, 
land (autodetect or user-invoked), and topic identifier. JO 
For example, a help structure <in C language; can be: 



urwo H**p Sourc* < 
dm Subject; 

M Kind: 35 

cfcar •pTopicSicwHi >: 

which can be filled by: 

40 

Suopci cqmi to reXT^ SUBSTITUTION 
*iod crxvmk io AUTO 

and p Tdptc String pointing to 'Text Substation." 45 

Referring *° FIG. II. the pr o cessin g of help inform** 
tic* in display engine 350 will now be described in 
detail. Help information Htn^ 335 a ^-»«K ?T r cog. 
Uinmg text 336 and rules 334 Helds. Lc-> help informs* 
tton teat 336 is linked to help information rales 334. In 30 
•ddiuon. a tag 1102 is provided for representing the 
solution that a role produces. Display engine 350 
matches tag 1102 with a solution tag 1101 from infer- 
ence engine 340. The corresponding text (from text 336) 
« the actual text sent as heip information 360 to display 55 
device 105. 

The organization of rules 334 is as follows, ic contains 
the following fiddi: Grp. Rule*. ForC#. Var#. Var. 
Va|, Bind. Key W. and Q#. Grp is a rule group. Group 
O n always ihe group in which rules are placed that will 60 
give a solution. If these rules cause any other rules to 
fire, these rules are in another group. Rule* is the num- 
ber of ihe rule. The rules are sorted by rule number, 
because one may want to try to fire one rule before 
another. PorCtf is a premise or conclusion number. The 65 
records in the table are aiso sorted by PorCff. The 
conclusion is number 0 because it is the first thing pulled 
out of the table when inference engine 340 starts to fire 



